Database management method, database management system, and processing program therefor

ABSTRACT

A method of increasing a processing performance by setting a suitable upper limit of a resources count for each processing request according to an arrangement of hardware such as a storage device or to contents of the processing request. A processing request acceptor accepts the processing request as a data query. An auxiliary storage device forms a storage area where a database is stored. A data operation executor analyzes the accepted processing request and executed the data operations on the basis of the analyzed result. A resource manager manages the respective data operations allocated to generated processes or threads. A buffer manager caches data of the data operations upon execution of the data operations from the auxiliary storage device to a memory, and determines whether or not the data as the target of the data operations are present in the cache.

CROSS-REFERENCE TO RELATED PATENT APPLICATIONS

Japan Priority Application 2009-186956, filed Aug. 12, 2009 includingthe specification, drawings, claims and abstract, is incorporated hereinby reference in its entirety. This application is a Continuation of U.S.application Ser. No. 12/703,661, filed Feb. 10, 2010, incorporatedherein by reference in its entirety.

BACKGROUND OF THE INVENTION

The present invention relates to a database management technique whichcan be applied widely to a database management system (DBMS).

Such a technique as disclosed in JP-A-2007-249468 has been so faremployed for a database management system to dynamically allocate CPUresources and execute a database processing request.

As the need for large-scale analysis is increasing in these years, sucha technique as disclosed in JP-A-2007-34414 is employed, whereinhigh-speed processing is required by parallel processing which utilizesmany resources including processes and threads within a databasemanagement system.

Further, even with respect to data operations such as index creation,data insertion and data update in the database management system, such atechnique as to increase the processing speed by parallelly processing asingle processing request from a user or an application program has alsobecome popular.

SUMMARY OF THE INVENTION

Such processing requires use of many resources including processes andthreads. However, there exists such a state that allocation of even anincreased number of resources results in the fact that a performancecannot be increased depending upon, for example, the input/outputperformance of a storage device. In the case of, for example, processesor threads, even allocation of an increased number of resources in sucha state involves an increased cost necessary for switching suchprocesses or threads and so on, and in some cases, even increase of theresources count beyond a predetermined value reversely deteriorates theperformance.

Such a system as an operating system has generally an upper value forthe number of resources usable for the entire system. There occurs, insome cases, such a situation that, when a plurality of processingrequests are executed and one of the executed processing requestsexecuted firstly uses resources up to its upper limit, a necessarynumber of resources cannot be allocated to the next processing request,thus resulting in a low performance.

In the database management system, on the other hand, when each accessis made to each of threads prepared for accesses to already stored datafor example, the access can be made with a less number of threads. Inother words, in order to processing a request with use of an optimumnumber of processes or threads, it becomes important to determine anupper limit value for the number of processes or threads.

An object of the present invention is to increase a processingperformance by setting a suitable upper limit for the number ofresources for each of processing requests depending upon the arrangementof hardware such as a storage device or the contents of each processingrequest.

In accordance with an aspect of the present invention, the above objectis attained by providing a database management system which includes aprocessing request acceptor which accepts a processing request as a dataquery; an auxiliary storage device in which storage areas for storingdata stored in a database are arranged; a data operation executor whichanalyzes the accepted processing request and operates a plurality ofpieces of data on the basis of the analyzed result; a resource managerwhich manages each of the data operations allocated to generatedprocesses or threads; and a buffer manager which caches data as a targetof the data operation from the auxiliary storage device into a memoryupon execution of the data operations and determines whether or not thedata as the target of the data operations is present in a cache. Whenthe data operation executor executes the data operations, the buffermanager determines whether or not the data is present in the cache. Theresource manager determines the usable state of the processes or threadsin the data operations when the data is not present in the cache. Whensome of the processes or threads are free or usable, the resourcemanager sends an access request of caching data as the target of theexecuted data operations in the memory to the auxiliary storage devicein order to execute the data operations through the processes orthreads. When all the processes or threads are already used, theresource manager executes the data operations after some of theprocesses or threads are released or free. In the presence of the datain the cache, the resource manager executes the data operations.

In the present invention, since an upper limit for the number ofresources allocated to a single processing request is set in thedatabase management system, the resources can be efficiently used.

Other objects, features and advantages of the invention will becomeapparent from the following description of the embodiments of theinvention taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a conceptual view for explaining an each-requestresources-count determiner for determining the number of resources foreach processing request in the present invention;

FIG. 2 shows a schematic configuration of a computer system in anembodiment of the present invention;

FIG. 3 is a flow chart for explaining details of the each-requestresources-count determiner;

FIG. 4 schematically shows a table for explaining schema definitioninformation;

FIG. 5 schematically shows a table for explaining storage arrangementinformation;

FIG. 6 schematically shows a diagram for explaining the storagearrangement information when the hierarchy of a storage device is madecomplex;

FIG. 7 schematically shows a table for explaining mapping informationabout schema and storage:

FIG. 8 shows a flow chart for explaining details of the each-requestresources-count determiner when an I/O performance is used as thestorage arrangement information;

FIG. 9 schematically shows a table for explaining an example of thestorage arrangement information when the I/O performance is treated asthe storage arrangement information;

FIG. 10 is a flow chart for explaining the operation when resources areallocated to each operation target table in linking operation;

FIG. 11 is a flow chart for explaining the operation of the dataoperation executor for executing operations involved by input/output(I/O) to/from a disk;

FIG. 12 schematically shows a table for explaining a relationshipbetween a reference resources count and a disk device;

FIG. 13 schematically shows a table for explaining performancestatistical information;

FIG. 14 is a diagram for explaining the effects of the resources countallocation in the linking operation;

FIG. 15 is a flowchart for explaining the resources count allocationwhen a linking sequence in the linking operation is considered; and

FIG. 16 schematically shows a linking order coefficient managementtable.

DESCRIPTION OF THE EMBODIMENTS Embodiment 1

A first embodiment of the present invention will be explained withreference to the accompanying drawings.

FIG. 2 shows, as an example, a schematic configuration of a computersystem in an embodiment of the present invention.

A computer system 201 includes a CPU 202 and a main storage device 203.The computer system is connected to a storage subsystem 205 via astorage area network 204. The computer system is also connected to manyclient hosts 206 each having a database access processor 207 via anetwork 208.

Database storage areas 210 for storing data to be managed by a databasemanagement system 101 are provided in areas of a plurality of diskdevices 209 within the storage subsystem 205. The storage subsystem 205also has a controller 214 for managing storage arrangement information212 including a correlation between data storage areas 215 and the diskdevices 209.

The storage subsystem 205 may be formed as a disk device built in thecomputer system 201.

A management server 211 is a server for managing a storage area networkenvironment and contains storage management software 213 which managesthe storage arrangement information 212.

The storage management software 213 may be built in the storagesubsystem 205.

The database management system 101 is provided in the main storagedevice 203.

The database management system 101 has a processing request acceptor 216as a already known means for accepting a processing request includingdata search from the client host 206, a data operation executor 218 asan already known means for causing the database management system 101 toexecute the data operations provided in the database storage area 210,schema definition information 219 such as information about databasetable structure, a resource manager 221 for causing the databasemanagement system 101 to hold processes or threads and allocating theprocessing operation, an each-request resources-count determiner 217 fordetermining the number of resources for each processing request, mappinginformation 220 of schema and storage arrangement indicating a tabledefinition etc. and the disk device having the data management areawhich is storing the table definition etc., and a reference resourcescount 222 as a threads count which can get the best I/O performance perone disk device.

The reference resources count 222 can be derived from experimentalvalues or the like for the same hardware arrangement. In the presentembodiment, a reference-resources-count/disk-device table 223 showing arelationship between disk device ID 1201 such as a model numberindicating the type of the disk device 209 and the reference-resourcescount 222 is stored.

The processing operations of the aforementioned respective processorsare executed under control of the CPU 202. In this connection, therespective processors may be called also as corresponding processingmeans. The respective processors can be implemented by hardware (forexample, a circuit), a computer program, an object or by combining these(for example, by executing part of the processing under control of thecomputer program and by executing part of the processing under controlof the hardware circuit). Each computer program can be read from astorage resource (such as a memory) provided in a computer machine. Thecomputer program may be installed in the storage resource via arecording medium such as CD-ROM or DVD (Digital Versatile Disk), or maybe downloaded via a communication network such as the Internet or anLAN.

FIG. 12 schematically shows a table for explaining thereference-resources-count/disk-device table 223. A correlation betweenthe disk device ID 1201 such as a model number indicating the type ofthe disk device and the reference-resources count 222 is stored in thetable.

The reference-resources-count/disk-device table 223 may be used so thatthe database management system 101 acquires performance statisticalinformation 224 upon data operation execution and determines thereference-resources count 222 corresponding to the associated diskdevice 209 from the performance statistical information about the diskdevice 209.

Since such performance statistical information can be acquired generallyby the database management system 101 or by the operating system, thesystem, for example, can measure the number of inputs/outputs per onesecond (TOPS), detect an IOPS when operated with one resource and thestate that the IOPS cannot be increased any longer even if the resourcescount is increased, and employ the resources count when the IOPS reachesits upper limit as the reference-resources count

FIG. 13 schematically shows a table for explaining the performancestatistical information 224.

In the present embodiment, the performance statistical information 224includes a storage area ID 403, a maximum IOPS 1301 so far generated,and a number 1302 of resources having accessed to the area uponacquisition of the maximum IOPS.

Although the resources count is treated as a threads count in thepresent embodiment, similar processing can be carried out even for thenumber of the other resources such as a processes count.

The database management system 101 generally has a buffer managementfunction 226 of caching disk data in the memory and managing whether ornot the data is present in a DB buffer 227 for the purpose of increasinga data operation performance.

FIG. 1 shows a schematic diagram for explaining the each-requestresources-count determiner for determining a resources count for eachprocessing request in the present invention. The database managementsystem 101 has a processing request executor 105 for accepting andexecuting a processing request from the client host 206.

Though such a processing request is usually issued from a businessapplication or the like, such a request may also be issued by a userfrom the client host computer 206 as a terminal or the like to thedatabase management system 101 to process the processing request.

In the processing request executor 105, the processing request isaccepted by the processing request acceptor 216 for accepting theprocessing request, and the processing request is parsed, optimized andconverted to an execution logic as a group of data operationinstructions including data updating in a table or data readingtherefrom. The data operation executor 218 reads such execution logicand executes the data operation.

The each-request resources-count determiner determines a search targettable from the analyzed result on the basis of the schema definitioninformation 219 (step 102).

On the basis of the storage arrangement information 212 and the mappinginformation 220 of a scheme and storage arrangement, the each-requestresources-count determiner acquires a storage arrangement in theoperation target table indicating which disk devices 209 data in tableslocated in (step 103).

On the basis of the acquired storage arrangement, the each-requestresources-count determiner determines a maximum threads count suitablefor each processing request corresponding to the storage arrangement(step 104).

FIG. 3 is a flow chart for explaining details of the each-requestresources-count determiner 217, and corresponds to details of theeach-request resources-count determiner in FIG. 1.

The each-request resources-count determiner 217 reads the schemadefinition information 219 (step 301), and prepares a list of operationtarget tables included in the processing request analysis result (step302).

The each-request resources-count determiner then reads storagearrangement information from the storage management software 213 or fromthe controller 214 of the storage subsystem 205 (step 303).

The storage arrangement information 212 indicates the number of physicaldisk devices in which the area being used is formed, and can be acquiredfrom the controller 214 of the storage subsystem 205 or from the storagemanagement software 213 for management of the storage subsystem 205.

Further, the each-request resources-count determiner reads the mappinginformation 220 of a scheme and storage arrangement possessed by thedatabase management system 101 (step 304), and combines the mappinginformation 220 of a scheme and storage arrangement and the storagearrangement information obtained in the step 303 to obtain the storagearrangement information 212 about the operation target table beingstored (step 305).

The each-request resources-count determiner now reads a referenceresources count as a threads count per one disk device (step 306),multiplies the storage arrangement information 212 obtained in the step305, that is, the number of the arranged disk devices 209 by thereference resources count 222, and determines a suitable threads countfor each processing request (step 307).

In this connection, a disk device rotational speed, an input/outputthroughput performance or a response performance in place of the diskdevices count may also be used as the storage arrangement information212 to obtain similar processing operation.

FIG. 4 schematically shows a table for explaining the schema definitioninformation 219.

The schema definition information 219 includes a table name 402 for anoperation target, a table ID 401 for identifying a table in theprocessing interior, and a storage area ID 403 as an ID of a storagearea in which the table is actually stored.

In this connection, the table name or the storage area name may be alsoused as an ID.

Even an index prepared for the purpose of high-speed search similarlyhas information about an index name 405, an index ID 404, an ID 403 ofan area where the index name and the index ID 404 are stored, and an ID401 of the table in which the index is defined.

In the present embodiment, the schema definition information is storedin the memory. However, the schema definition information may be storedin another location, for example, in the disk device, so long as theinformation can be read out upon execution of the each-requestresources-count determiner.

FIG. 11 is a flow chart for explaining the data operation executor 218for executing the operation involved by input/output to/from the diskdevice.

The data operation executor 218 first reads the execution logic (step1101), and determines whether or not the execution logic can beparallelly processed as previously defined (step 1107).

When the execution logic can be parallelly processed, the operationtarget is not cached in the buffer, and the data operation executorconfirms whether or not the operation target is present only in the disk(step 1701).

When the operation target is not cached in the buffer, the dataoperation executor confirms whether or not the threads count now beingused fails to reach its upper limit (step 1102). When the threads countnow being used reaches its upper limit, the data operation executorwaits for a released thread (step 1103). When the threads count beingused fails to reach its upper limit, the data operation executorallocates the data operation to a thread (step 1104) and executes thedata operation (step 1106).

When the execution logic can be parallelly processed and when theoperation target is cached in the buffer, the data operation executorsimply executes the data operation (step 1105).

And the above steps are repeated until the execution logic is completed(step 1105).

When the data operation executor reads the cached data using the DBbuffer 227, even allocation of many threads fails to obtain a greateffect.

To avoid this, it is considered to determine whether or not the dataoperation target is cached upon execution of the processing request, toread the data as it is when the data is cached in the DB buffer 227, andto allocate the data to thread and execute it when the data is notcached.

When the data operation executor 218 executes the aforementionedprocessing operations, resource allocation considering the cached stateof the data can be attained.

FIG. 5 schematically shows a table for explaining the storagearrangement information 212.

The storage arrangement information 212 includes a logical device ID 502that the database server can recognize the logical device and a diskdevices count 501 indicating the number of disk devices used for thearea.

With respect to the disk devices count, the disk devices count can havea relationship of a plurality of correlations overlapped when thehierarchy becomes complex by virtualizing the storage devices or thelike, and when the area has a plurality of spanned areas, the diskdevices count can be approximated to an average of the plurality ofareas.

FIG. 6 schematically shows a diagram for explaining the storagearrangement information 212 when the hierarchy of storage devicesbecomes complex.

In this example, a plurality of disk devices 209 are combined into aRAID group 601, and each of such RAID groups 601 is divided into logicaldevices 602, some of the divided logical devices 602 are extracted fromthe plurality of RAID groups 601 and combined into a single logicaldevice 603.

In such a case, an average disk devices count as all the RAID groups isassumed to be the disk devices count 501 corresponding to the databasestorage area 210.

The respective disk devices counts may be weighted on the basis of aratio among disk capacities being used, and the disk devices count 501corresponding to the database storage area 210 may be determined.

FIG. 7 schematically shows a table for explaining the mappinginformation 220 of a scheme and storage arrangement.

The mapping information 220 of a scheme and storage arrangement includesa storage area ID 403 indicating an area where data is stored and alogical device ID 502 corresponding to the storage area.

In this case, one storage area may have a plurality of logical devicesor a plurality of storage areas may have a single logical device.

As examples other than the above example, various arrangements using thefunctions of the storage subsystem and operating system are considered.Even in such cases, the disk devices count 501 corresponding to thedatabase storage area 210 can be determined in the same manner as in theaforementioned case.

In this case, the storage arrangement information 212 may be treated asthe storage arrangement information 212 simply with the I/O performanceof the storage area as in the case of the disk devices count.

FIG. 8 is a flow chart for explaining details of the each-requestresources-count determiner 217 for each processing request similarly toFIG. 3, and shows an example when the I/O performance is used as thestorage arrangement information.

In this flow chart, the operations of steps 301 to 305 are similar tothe contents already explained in FIG. 3.

The each-request resources-count determiner reads a threads count perunit I/O performance as the reference resources count in place ofreading the reference resources count as a threads count per one storagein the step 306 of FIG. 3 (step 801).

The each-request resources-count determiner, in place of the step 307 ofFIG. 3, derives an optimum threads count for each processing request bymultiplying the threads count per unit I/O performance by the I/Operformance of the storage area (step 802).

FIG. 9 schematically shows a table for explaining an example of thestorage arrangement information when the I/O performance is treated asthe storage arrangement information 212.

In this case, the storage arrangement information 212 includes thelogical device ID 502 which can be recognized by the database server,and also an I/O performance 901 indicating how many inputs/outputs thearea can produce.

When the data arrangement is biased, the system cannot possibly exhibita theoretical performance. In the present invention, however, whensearching objects are evenly distributed, the system can exhibitespecially a high effect. When a scale of stored data is sufficientlylarge, the data are expected to be evenly distributed.

Embodiment 2

A second embodiment corresponds to an example when the system waits fora linkage process of processing data of a plurality of tables inassociation with each other, and the schematic configuration of itscomputer system is similar to that of FIG. 2.

When the system waits for such a linkage process, in order to operatethe plurality of tables simultaneously, it is required to allocate asuitable resources count to each of the operation target tables.

FIG. 10 is a flow chart for explaining the operations of a linkageprocess of allocating a resources count to each of operation targettables.

In the flow chart, the operations of steps 301 to 307 are similar to thecontents already explained in FIG. 3.

In this flow chart, the operation of determining a suitable resourcescount for each processing request by multiplying the disk devicearrangement count of the step 307 by the reference resources count isrepeated by a number of times corresponding to the number of theoperation target tables (step 1001).

The obtained resources count for each table is stored as a resourcescount upper limit for each operation target table (step 1002).

At this time, the data operation executor, which is similar to that inFIG. 11, checks whether or not a threads count currently being usedreaches its upper limit in a step 1102 for each table. When the currentthreads count exceeds its upper limit allocated to one table, the dataoperation executor executes a step (step 1103) to wait for threadrelease.

FIG. 14 is a schematic diagram for explaining the effect of resourcescount allocation in the linkage process. In this case, the storage area210 having 4 disk devices 209 and the storage area 210 having two diskdevices 209 are provided. A table 1401 having data stored therein isprovided in each of the storage areas.

When the system executes the linkage process to match data in two tablesunder such a condition, merely a sum of resources count upper limits ofall the tables can be treated as an entire resources count upper limit.As explained in the above embodiment, however, when resources countupper limits are set for respective tables A and B in search thereof,search of the table A is executed using resources corresponding to 4disk devices, and search of the table B is executed using two diskdevices. In accordance with the present embodiment in this way, evenwhen an access to a plurality of storage areas is made for a singledatabase processing request, a suitable resources count allocation canbe attained for each area.

In general, when a system has a linkage process, data to be linked laterin linkage order tend to be read more than data to be linked earlier inlinkage order. Thus a method of setting a resources count requirement ofallocating a larger number of resources to the data to be linked laterin linkage order than the data to be linked earlier may be employed.

FIG. 15 is a flow chart for explaining the resources count allocationwhen consideration is paid to a linkage order in a linkage process.

In the flow chart, the operations of steps 301 to 307, 1001, and 1002are similar to the contents already explained in FIG. 10.

In a step 1501 after the step 307 of determining a suitable resourcescount for each processing request by multiplying the number of arrangeddisk devices by the reference resources count, the resources count ismodified by multiplying it by a linkage order coefficient 1602associated with a linkage order 1601.

The linkage order coefficient, which is previously kept in the system asa constant value, has a value smaller than 1. Whether or not data isprocessed earlier or later in linkage order is determined and easilydiscriminated by the processing request acceptor.

FIG. 16 is a schematic diagram for explaining a linkage ordercoefficient management table 225.

The linkage order coefficient management table 225 shows a relationshipbetween the linkage order 1601 and the linkage order coefficient 1602.The linkage order coefficient 1602 is set at 1 in the last linkage andat a value smaller than 1 in the order earlier therethan. The earlierthe linkage order is the smaller the linkage order coefficient is.

Since the linkage order coefficient depends on the number of pieces ofdata to be accessed in the table, the coefficient cannot determinedbefore execution of the access request. As an example, the linkage ordercoefficient is considered merely based on the linkage order to bepreviously set at 0.9 for linkage one previous to the last linkage, 0.8for linkage two previous to the last linkage, and 0.1 for linkagessmaller than 0.1.

As has been explained above, when data are stored in a plurality ofstorage devices and many resources are used, the system can efficientlyuse such resources, which leads to its high-speed operation as a whole.

The embodiments of the present invention have been explained above.However, these embodiments are exemplified merely for the purpose ofexplaining the present invention, and the scope of the invention is notlimited only to the illustrated embodiments. The present invention canbe embodied in various ways without departing from the gist of theinvention.

It should be further understood by those skilled in the art thatalthough the foregoing description has been made on embodiments of theinvention, the invention is not limited thereto and various changes andmodifications may be made without departing from the spirit of theinvention and the scope of the appended claims.

1. A database management method in a database management systemcomprising auxiliary storage devices having a storage area for storing adatabase therein, the method comprising the steps of: holding, by astorage unit, schema definition information including information abouta table structure of the database and storage arrangement informationincluding a mapping with a storage area for storing data in thedatabase, and holding an upper limit of a threads count by correlatingwith the storage devices; accepting, by a processing request acceptor, aprocessing request as a data query; analyzing, by a data operationexecutor, the accepted processing request, referring the schemadefinition information and the storage arrangement information,obtaining a data in the database accessed in accordance with theprocessing request by accessing the plurality of storage devices whichstore the data in the database, and executing data operations for aplurality of obtained data on the basis of the analyzed result;managing, by a resource manager, the respective data operationsallocated to generated threads for each processing request; andobtaining, by an each-processing-request each-request resources-countdeterminer, the upper limit of the threads count correlated with therespective storage devices accessed in accordance with the processingrequest, calculating the obtained upper limit of the threads count, anddetermining an upper limit of the threads count for the each processingrequest.
 2. A database management method according to claim 1, whereinthe each-processing-request resources count determiner refers to thethreads count used by the processing request for each operation of theaccepted processing request from performance statistical informationabout the database management system acquired upon execution of pastprocessing requests, and calculates an upper limit value of the threadscount to be used.
 3. A database management method according to claim 1,wherein the each-processing-request resources count determinerdetermines an upper limit value of the threads count used for the eachprocessing request when an execution on the basis of the threads countcalculated from an I/O performance of the storage device accessed inaccordance with the processing request when an execution.
 4. A databasemanagement system comprising auxiliary storage devices having a storagearea for storing a database therein, the system comprising: a storageunit which holds schema definition information including informationabout a table structure of the database and storage arrangementinformation including mapping with a storage area for storing data inthe database, and holds an upper limit of a threads count by correlatingwith the storage devices; a processing request acceptor configured toaccept a processing request as a data query; a data operation executorconfigured to analyze the accepted processing request, refer the schemadefinition information and the storage arrangement information, obtain adata in the database accessed in accordance with the processing requestby accessing the plurality of storage devices which store the data inthe database, and execute data operations for a plurality of obtaineddata on the basis of the analyzed result; a resource manager configuredto manage the respective data operations allocated to generated threadsfor each processing request; and an each-processing-request each-requestresources-count determiner configured to obtain the upper limit of thethreads count correlated with the respective storage devices accessed inaccordance with the processing request, calculate the obtained upperlimit of the threads count, and determine an upper limit of the threadscount for the each processing request.
 5. A database management systemaccording to claim 1, wherein the each-processing-request resourcescount determiner is configured to refer to the threads count used by theprocessing request for each operation of the accepted processing requestfrom performance statistical information about the database managementsystem acquired upon execution of past processing requests, andcalculate an upper limit value of the threads count to be used.
 6. Adatabase management system according to claim 1, wherein theeach-processing-request resources count determiner is configured todetermine an upper limit value of the threads count used for the eachprocessing request when an execution on the basis of the threads countcalculated from an I/O performance of the storage device accessed inaccordance with the processing request when an execution.
 7. Anon-transitory computer readable storage medium storing a databasemanagement program in a database management system comprising auxiliarystorage devices having a storage area for storing a database therein,the database management program executes the steps of: holding, by astorage unit, schema definition information including information abouta table structure of the database and storage arrangement informationincluding mapping with a storage area for storing data in the database,and holding an upper limit of a threads count by correlating with thestorage devices; accepting, by a processing request acceptor, aprocessing request as a data query; analyzing, by a data operationexecutor, the accepted processing request, referring the schemadefinition information and the storage arrangement information,obtaining a data in the database accessed in accordance with theprocessing request by accessing the plurality of storage devices whichstore the data in the database, and executing data operations for aplurality of obtained data on the basis of the analyzed result;managing, by a resource manager, the respective data operationsallocated to generated threads for each processing request; andobtaining, by an each-processing-request each-request resources-countdeterminer, the upper limit of the threads count correlated with therespective storage devices accessed in accordance with the processingrequest, calculating the obtained upper limit of the threads count, anddetermining an upper limit of the threads count for the each processingrequest.
 8. A non-transitory computer readable storage medium storing adatabase management program according to claim 1, wherein theeach-processing-request resources count determiner refers to the threadscount used by the processing request for each operation of the acceptedprocessing request from performance statistical information about thedatabase management system acquired upon execution of past processingrequests, and calculates an upper limit value of the threads count to beused.
 9. A non-transitory computer readable storage medium storing adatabase management program according to claim 1, wherein theeach-processing-request resources count determiner determines an upperlimit value of the threads count used for the each processing requestwhen an execution on the basis of the threads count calculated from anI/O performance of the storage device accessed in accordance with theprocessing request when an execution.